The present disclosure relates generally to message header modification and more specifically to an improved system and method for session initiation protocol (SIP) message header modification.
As used herein, the terms “User Equipment” and “UE” can refer to wireless devices such as mobile telephones, personal digital assistants, handheld or laptop computers, and similar devices or other user agents (“UAs”) that have telecommunications capabilities. In some embodiments, a UE may refer to a mobile, wireless device. The term “UE” may also refer to devices that have similar capabilities but that are not generally transportable, such as desktop computers, set-top boxes, or network nodes. Throughout this disclosure, UE may refer to any SIP UA such as a wireless device, set-top box, or other communication devices and is interchangeable with the term UA.
In Third Generation Partnership Project (3GPP) systems, an internet protocol (IP) multimedia subsystem (IMS) allows for the delivery of IP multimedia services. Using IMS, a UA may transmit and receive multimedia and/or voice packet switched (PS) communications via a base station implementing one or more IMS Functional Components. To implement IMS, networks rely upon session initiation protocol (SIP) to provide a text-based signaling protocol that may be used to communicate between a UA and the IMS Core Network (CN), between the IMS CN and Application Servers, and between various other components of the IMS Network.
SIP messages may include several elements such as mandatory request uniform resource identifiers (URIs) or status codes, textual status representations, and a body containing zero or more body parts (if at least one body is present, additional headers or header fields may also be present describing the body). SIP message may be one of the following types: a SIP method, a SIP request or a SIP response. In the present disclosure, the terms SIP method and SIP request are interchangeable and may refer to the same SIP message type. If the SIP message includes zero bodies, the message includes a Content-Length header having a field set to 0. The SIP messages also include mandatory headers with SIP transaction or session information, mandatory headers with user and authentication information, mandatory headers with routing information, and optional headers that can be used by IMS applications and services to communicate application and/or service specific information. Therefore, existing SIP messages tend to be verbose and are generally required to include substantial amounts of information. As a result, SIP has substantial overhead—in some cases, the average size of a SIP message without payload may exceed 700 Bytes.
In addition to the mandatory header fields, SIP messages may include any number of optional fields. Because SIP is designed to be extended, future extensions may define new methods and associated header fields at any time. As a result, applications and services can define new extensions of the protocol and thereby define new application or service specific SIP headers to be included within a SIP message.
Depending upon a UA's capabilities, the UA may or may not be able to use the optional headers included in a SIP message. Generally, any new headers are optional for applications and services that do not support the extensions. In many cases, the absence of a SIP option tag suggests that the UA does not support the extension and its associated header or header fields. If the UA does not support the service, the UA may be configured to disregard the unusable header or header fields. Unfortunately, because an application or service initiating an IMS session may not be aware of the capabilities of its peer, the application or service may insert multiple headers or header fields into SIP messages under the assumption the headers will be used by the peer UA. If, however, the peer UA does not support the service, the additional information will be discarded and its transmission wasted.
FIG. 1 is an illustration of a UA receiving a SIP message including optional SIP headers. In the example, UA 20 does not support the service that relies upon the optional headers. In a first step, UA 10 sends a SIP INVITE message 12 with several optional headers (see underlined text) to proxy call session control function (P-CSCF) 14 for delivery to UA 20. In this example, UA 20 does not support the application or service associated with the optional headers.
In one implementation, P-CSCF 14 is an entity defined by 3GPP TS 23.228 IMS. P-CSCF 14 is the first contact point for a UA within the IMS core network (CN) subsystem and, as such, P-CSCF 14 may behave like a Proxy (e.g., as defined in IETF RFC 3261 SIP: Session Initiation Protocol). Accordingly, P-CSCF 14 may accept requests and then service them internally, or forward them on to another network component.
After receiving SIP INVITE message 12, P-CSCF 14 routes message 12 to serving CSCF (S-CSCF) 16. S-CSCF 16 may be an entity defined by 3GPP TS 23.228 IMS, for example. S-CSCF 16 may then provide session control services for the UA and maintain a session state as needed by the network operator for support of those services.
S-CSCF 16 then routes the SIP INVITE message 12 to P-CSCF 18 and UA 20. As shown in FIG. 1, SIP INVITE message 12 received by UA 20 includes the original optional headers that were setup and transmitted by UA 10 in the original SIP INVITE transmission. In this example, however, because UA 20 does not use the optional headers, the headers are dropped by UA 20 during message processing or parsing. As such, the original transmission of the headers represents a wasted transmission because the information was never used, and is incapable of being used, by UA 20. Optional headers may be disregarded by UAs, UEs, peer applications or services if they cannot be used.
With respect to outgoing transmissions, if a UA or an Application Server (AS) supports a certain SIP extension, the UA or AS inserts optional headers into the message before sending the message to the IMS network. The values of the optional headers depend upon the type of SIP extension that is supported by the UA. The header values can be dynamically changed within a SIP session (e.g., Date, and Timestamp headers), or may be static (e.g., User-Agent, Allow, and Allow-Events headers) and have the same value for an extended period of time. The static values can be changed, for example, when the UA is upgraded or a configuration is modified by a user. Accordingly, there may be a subset of SIP headers that include relatively static values that are not changed for extended periods of time.
In addition to the optional SIP headers that may be included in a SIP message based upon the capabilities of a UA or AS, SIP messages headers may also include routing information. For example, a simple SIP message, while traversing multiple IMS networks, may accumulate routing information in the form of Via, Record-Route and Route SIP headers. The size and number of the headers that contain routing information can significantly affect performance of the UA's processor when the message is processed. The processing of additional routing headers may also consume extra power of a wireless UA when the UA receives or transmits the data. An example of the SIP PRACK message with extra Via-headers is presented below in Table 1.
TABLE 1PRACK sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0Via:SIP/2.0/UDPpcscf2.home2.net:5088;comp=sigcomp;branch=z9hG4bK876t12.1,SIP/2.0/UDPscscf2.home2.net;branch=z9hG4bK764z87.1,SIP/2.0/UDPscscf1.home1.net;branch=z9hG4bK332b23.1,SIP/2.0/UDPpcscf1.home1.net;branch=z9hG4bK431h23.1,SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 66From: <sip:user1_public1@home1.net>;tag=171828To: <tel:+1-212-555-2222>;tag=314159Call-ID: cb03a0s09a2sdfglkj490333Cseq: 128RAck: 9022 127 INVITEContent-Length:0
As can be seen from the SIP message illustrated in Table 1, the size of the extra Via-headers (at least one Via header is mandatory) is 42% of the total message size (in the example, total message size is 570 bytes, total size of the 2nd-5th Via-headers is 334 bytes). As a result, the IMS stack that processes the message will parse 12 SIP headers, but would only process 8 SIP headers if the extra Via-headers were removed from the message.
Another example of a SIP ACK message is presented in Table 2.
TABLE 2ACK sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0Via: SIP/2.0/UDPSIP/2.0/UDPpcscf2.visited2.net:5088;branch=z9hG4bK361k21.1,icscf2_s.home1.net;branch=z9hG4bK871y12.1,SIP/2.0/UDPSIP/2.0/UDP Token(scscf2.home1.net;branch=z9hG4bK764z87.1,SIP/2.0/UDPscscf1.home1.net;branch=z9hG4bK332b23.1,SIP/2.0/UDPpcscf1.home1.net;branch=z9hG4bK431h23.1)@home1.net;tokenized-by=home1.net,SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 66From: <sip:user1_public1@home1.net>;tag=171728To: <tel:+1-212-555-2222>;tag=314259Call-ID: cb03a0s09a2sdfglkj490233Cseq: 128 ACKContent-Length: 0
As shown in Table 2, the total size of the message including extra Via-headers is 641 bytes. The total size of the message with one Via-header would be 298 bytes. Accordingly, by removing extra routing headers, the message size may be reduced by 54%. In that case, the IMS stack would parse only 7 SIP headers as compared to 12 when the extra Via-headers are presented in the message.
In many cases, SIP message structure is inefficient and verbose resulting in substantial amounts of data being transmitted via the network that will ultimately be discarded by a UA or other network component receiving the information. For example, there are several categories of information that need not be transmitted, or only transmitted intermittently resulting in a decrease in the volume of data being transmitted. The categories include SIP message elements (such as header fields) that are ultimately discarded by a UA, SIP message elements with static values, and extra or superfluous routing headers. Without a mechanism for controlling the information included in SIP transmissions, there may be excessive use of IMS Network resources, excessive use of the Radio Access Network (RAN) by wireless UAs, delays for parsing and processing of the optional and routing headers by the components of IMS network, and unnecessary consumption of wireless UA resources (e.g., battery usage, and memory consumption required to process and manipulate the optional headers and routing headers). As such, there is a need to control and modify optional and routing headers present in underlying SIP messages within an IMS network implementation.